src/entities/auth/api/authApi.ts (1)

3-3: 임포트 경로는 절대 경로(@/...)로 통일해 주세요

Line 3의 상대 경로(../model/schemas)는 현재 프로젝트 컨벤션과 어긋납니다. 작은 차이지만 리팩토링/이동 시 경로 안정성이 크게 달라집니다.

빠른 수정안

-import {kakaoLoginResponseSchema} from '../model/schemas';
+import {kakaoLoginResponseSchema} from '@/entities/auth/model/schemas';

참고 문서: https://nextjs.org/docs/app/building-your-application/configuring/absolute-imports-and-module-aliases

As per coding guidelines 절대 경로 임포트(@/...) 사용.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/auth/api/authApi.ts` at line 3, The import of
kakaoLoginResponseSchema in authApi.ts uses a relative path; change the import
to use the project's absolute alias (e.g. replace "../model/schemas" with an
absolute import like "@/entities/auth/model/schemas") so the
kakaoLoginResponseSchema import follows the `@/`... convention used across the
codebase and remains stable during refactors.

src/pages/unit-editor/model/types.ts (1)

10-13: mode: Mode | null 도입에 맞춰 UnitFormProps를 판별 유니온으로 분리해 주세요.

현재 구조는 mode 값과 무관하게 unitIndex/핸들러 조합이 모두 허용되어, 런타임 분기 의존도가 커집니다. 모드별 props를 타입으로 강제하면 안전성이 더 올라갑니다.

🔧 제안 diff

-export interface UnitFormProps {
-  unit?: Unit;
-  unitIndex: number;
-  mode: Mode | null;
-  onCreateUnit: (unit: TUnitFormSchema) => void;
-  onUpdateUnit: (unitId: number, unit: TUnitFormSchema) => void;
-  onDeleteUnit: (unitId: number) => void;
-}
+type UnitFormBaseProps = {
+  onDeleteUnit: (unitId: number) => void;
+};
+
+type CreatingUnitFormProps = UnitFormBaseProps & {
+  mode: 'creating';
+  unitIndex: number;
+  unit?: never;
+  onCreateUnit: (unit: TUnitFormSchema) => void;
+  onUpdateUnit?: never;
+};
+
+type EditingUnitFormProps = UnitFormBaseProps & {
+  mode: 'editing';
+  unit: Unit;
+  unitIndex: number;
+  onUpdateUnit: (unitId: number, unit: TUnitFormSchema) => void;
+  onCreateUnit?: never;
+};
+
+type InactiveUnitFormProps = UnitFormBaseProps & {
+  mode: null;
+  unit?: never;
+  unitIndex?: never;
+  onCreateUnit?: never;
+  onUpdateUnit?: never;
+};
+
+export type UnitFormProps =
+  | CreatingUnitFormProps
+  | EditingUnitFormProps
+  | InactiveUnitFormProps;

공식 문서 참고: https://www.typescriptlang.org/docs/handbook/2/narrowing.html#discriminated-unions

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/unit-editor/model/types.ts` around lines 10 - 13, UnitFormProps
currently allows any combination of mode, unitIndex and handlers which weakens
type safety; change it to a discriminated union keyed on mode (the Mode type) by
creating separate interfaces (e.g., UnitFormCreateProps with mode: 'create' and
required onCreateUnit only; UnitFormEditProps with mode: 'edit', unitIndex:
number and required onUpdateUnit; UnitFormDeleteProps with mode: 'delete',
unitIndex: number and required onDeleteUnit) and export type UnitFormProps =
UnitFormCreateProps | UnitFormEditProps | UnitFormDeleteProps; ensure you
reference the exact symbols TUnitFormSchema, Mode, unitIndex, onCreateUnit,
onUpdateUnit and onDeleteUnit when renaming/organizing so callers and components
are updated to match the new discriminated union shape.

src/entities/assignment/model/schemas.ts (2)

13-19: 중첩 스키마 추출 고려

assignments 배열 내부의 객체 스키마가 인라인으로 정의되어 있습니다. 다른 곳에서 재사용 가능성이 있다면 별도 스키마로 추출하는 것도 좋습니다.

♻️ 중첩 스키마 추출 예시

+export const assignmentItemSchema = z.object({
+  course: z.string(),
+  section: z.string(),
+  assignment: z.string(),
+});
+
 export const assignmentScheduleSchema = z.object({
   date: z.string(),
   remainingDays: z.number(),
-  assignments: z.array(
-    z.object({
-      course: z.string(),
-      section: z.string(),
-      assignment: z.string(),
-    })
-  ),
+  assignments: z.array(assignmentItemSchema),
 });

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/assignment/model/schemas.ts` around lines 13 - 19, The inline
object schema used inside the assignments array should be extracted into a
reusable named schema: create a const like AssignmentItemSchema (or
AssignmentSchema) defined as z.object({ course: z.string(), section: z.string(),
assignment: z.string() }) and then replace the inline z.object(...) in
assignments with z.array(AssignmentItemSchema); export the new schema if it will
be reused elsewhere and update any type aliases or imports that should reference
AssignmentItemSchema instead of the inline object.

---

2-2: Zod import 스타일 일관성

import z from 'zod' (default import)를 사용하고 있는데, src/shared/model/schemas.ts에서는 import {z} from 'zod' (named import)를 사용합니다. 프로젝트 전체에서 일관된 스타일을 유지하는 것이 좋습니다.

참고: Zod는 두 방식 모두 지원하지만, named import가 더 일반적입니다.

♻️ named import로 통일

-import z from 'zod';
+import {z} from 'zod';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/assignment/model/schemas.ts` at line 2, Replace the default Zod
import used in this module ("import z from 'zod'") with the named import style
("import { z } from 'zod'") to match the project's existing convention (as seen
in the other schemas module); update any usages that reference the default
identifier if necessary so they continue to use the same symbol name "z" after
switching to the named import.

src/entities/unit/model/useUnitStore.ts (2)

15-15: 중복 export 패턴 정리 제안

useUnitStore가 named export (Line 15)와 default export (Line 51) 모두로 내보내지고 있습니다. 일관성을 위해 하나로 통일하는 것이 좋습니다. 프로젝트에서 주로 사용하는 패턴에 맞춰주세요.

♻️ named export만 유지하는 경우

 export const useUnitStore = create<UnitState>()(
   // ...
 );
-
-export default useUnitStore;

Also applies to: 51-51

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/unit/model/useUnitStore.ts` at line 15, The module currently
exports useUnitStore twice (both a named export at "export const useUnitStore"
and a default export later), causing duplicate export patterns; normalize to a
single export style by removing the default export and keeping the named export
useUnitStore (or vice versa if your project prefers default exports), update any
import sites to match the chosen style, and ensure the symbol useUnitStore is
the single exported identifier from this file.

---

24-29: 객체 프로퍼티 단축 구문 사용 제안

ES6 단축 구문을 사용하면 더 간결해집니다.

♻️ 단축 구문 적용

       storeFormData: (title, releaseDate, dueDate) =>
         set({
-          title: title,
-          releaseDate: releaseDate,
-          dueDate: dueDate,
+          title,
+          releaseDate,
+          dueDate,
         }),

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/unit/model/useUnitStore.ts` around lines 24 - 29, storeFormData
currently sets properties by repeating parameter names; update the object passed
to set in the storeFormData function to use ES6 property shorthand so it becomes
set({ title, releaseDate, dueDate }) instead of repeating each assignment;
modify the implementation in useUnitStore where storeFormData calls set to use
the shorthand while keeping the same parameter names and behavior.

src/shared/model/schemas.ts (1)

6-17: semesterCodeSchema와 submissionStatusSchema의 재사용성 확인

두 enum 스키마가 정의되어 있지만, src/shared/model/index.ts에서는 apiResponseSchema만 re-export되고 있습니다. 다른 모듈에서 이 스키마들을 직접 import하고 있다면 문제없지만, 일관된 public API를 위해 index.ts를 통한 re-export를 고려해 보세요.

♻️ index.ts에서 추가 export 제안

 export type {ApiResponse, UserType} from './common';
-export {apiResponseSchema} from './schemas';
+export {apiResponseSchema, semesterCodeSchema, submissionStatusSchema} from './schemas';

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/shared/model/schemas.ts` around lines 6 - 17, Re-export the two enum
schemas from the package entry so they’re available via the module index: add
semesterCodeSchema and submissionStatusSchema to the exports in the shared model
index (the module that currently re-exports apiResponseSchema) so other modules
can import them from the public API rather than hitting the schemas file
directly; update the index to export the symbols semesterCodeSchema and
submissionStatusSchema (from the schemas module) and run a quick compile/CI to
ensure no broken imports remain.

src/entities/unit/api/unitQueries.ts (1)

23-25: 간소화 가능한 arrow function

단일 표현식 반환이므로 중괄호와 return을 제거할 수 있습니다.

♻️ 간소화 제안

-      select: (data) => {
-        return data.response;
-      },
+      select: (data) => data.response,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/unit/api/unitQueries.ts` around lines 23 - 25, Simplify the
arrow function used as the select handler by converting the block body to a
concise body: remove the curly braces and the explicit return in the select:
(data) => { return data.response; } function so it becomes a single-expression
arrow function that directly returns data.response (refer to the select handler
in src/entities/unit/api/unitQueries.ts).

src/pages/unit-editor/ui/UnitList.tsx (1)

14-23: handleSelectUnit 함수 간소화 가능

단순히 onUnitClick을 호출하는 wrapper 함수입니다. inline으로 직접 사용하거나, 함수를 제거하고 onClick에서 직접 호출할 수 있습니다.

♻️ 간소화 제안

 export const UnitList = ({
   unitList,
   onUnitClick,
   selectedUnitId,
   onAddNewUnit,
 }: UnitListProps) => {
-  const handleSelectUnit = (id: number) => {
-    onUnitClick(id);
-  };
-
   return (
     <div className='flex flex-col h-full'>
       ...
         {unitList?.map(({id, title, assignmentCount}) => (
           <li
-            onClick={() => handleSelectUnit(id)}
+            onClick={() => onUnitClick(id)}
             key={id}
             ...

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/unit-editor/ui/UnitList.tsx` around lines 14 - 23, The
handleSelectUnit wrapper in UnitList simply forwards its id to onUnitClick;
remove handleSelectUnit and call onUnitClick directly from the JSX onClick
handlers (or inline arrow functions) to simplify code and reduce indirection,
updating any references to handleSelectUnit in UnitListProps usage to use
onUnitClick instead.

src/pages/manage-assignment/ui/AssignmentManageActionsBar.tsx (1)

28-33: 버튼 접근성 및 type 속성 개선 필요

1. 아이콘만 있는 버튼에는 스크린 리더를 위한 aria-label 추가가 권장됩니다.
2. type="button" 명시를 통해 폼 내부에서 의도치 않은 submit 방지가 가능합니다.

♻️ 접근성 개선 제안

-      <button onClick={handleOnEdit}>
+      <button type="button" onClick={handleOnEdit} aria-label="수정">
         <EditIcon className='w-3.5 h-4' />
       </button>
-      <button onClick={handleOnDelete}>
+      <button type="button" onClick={handleOnDelete} aria-label="삭제">
         <DeleteIcon className='w-3.5 h-4' />
       </button>

참고: MDN - Button type attribute

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/manage-assignment/ui/AssignmentManageActionsBar.tsx` around lines
28 - 33, AssignmentManageActionsBar currently renders icon-only buttons for
edit/delete without type or accessible labels; update the two buttons (the ones
invoking handleOnEdit and handleOnDelete and rendering EditIcon/DeleteIcon) to
include type="button" to prevent accidental form submits and add descriptive
aria-label attributes (e.g., aria-label="Edit assignment" and aria-label="Delete
assignment") so screen readers can announce their purpose.

src/entities/unit/api/unitMutations.ts (1)

8-14: 파라미터 네이밍 불일치

createUnit은 unitForm을, updateUnit은 unit을 사용하고 있습니다. 동일한 TUnitFormSchema 타입을 받으므로 일관된 네이밍을 권장합니다.

♻️ 일관성 개선 제안

   // 단원 수정 뮤테이션 옵션
   updateUnit: {
     mutationKey: ['updateUnit'],
-    mutationFn: ({unitId, unit}: {unitId: number; unit: TUnitFormSchema}) =>
-      updateUnit(unitId, unit),
+    mutationFn: ({unitId, unitForm}: {unitId: number; unitForm: TUnitFormSchema}) =>
+      updateUnit(unitId, unitForm),
   },

Also applies to: 20-21

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/unit/api/unitMutations.ts` around lines 8 - 14, The PR has
inconsistent parameter naming: createUnit expects unitForm while updateUnit uses
unit though both accept TUnitFormSchema; make names consistent across the
mutations by renaming the parameter in updateUnit (or in createUnit) to the same
identifier (e.g., unitForm) and adjust the mutationFn signature and any usages
accordingly so both createUnit and updateUnit accept a parameter named unitForm
of type TUnitFormSchema; update any related references in this file (including
the other occurrence around lines 20-21) to match the chosen name.

src/pages/select-assignment/AssignmentSelectPage.tsx (1)

38-41: 타입 안전성 개선 제안: backPath 타입 정의

location.state?.backPath가 any 타입으로 추론됩니다. React Router의 useLocation 제네릭을 활용하여 타입 안전성을 확보할 수 있습니다.

♻️ 타입 정의 예시

interface LocationState {
  backPath?: string;
}

const location = useLocation() as ReturnType<typeof useLocation> & {
  state: LocationState | null;
};

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/select-assignment/AssignmentSelectPage.tsx` around lines 38 - 41,
location.state?.backPath is inferred as any; make useLocation generic to type
the location.state so backPath is typed (e.g., define an interface LocationState
with backPath?: string and cast/use useLocation with that type). Update the
location usage where returnToPreviousPage reads location.state?.backPath so it
uses the typed location (refer to useLocation and returnToPreviousPage) and keep
the navigate fallback (?? -1) unchanged.

src/entities/course/api/courseApi.ts (1)

6-12: 인라인 스키마 정의 대신 별도 스키마 추출 고려

getAllCourses 응답 스키마가 함수 내부에 인라인으로 정의되어 있습니다. 이 스키마를 schemas.ts에 별도로 정의하면 재사용성과 테스트 용이성이 향상됩니다.

♻️ 스키마 분리 제안

src/entities/course/model/schemas.ts에 추가:

export const courseListResponseSchema = z.object({
  count: z.number(),
  courses: z.array(dashboardCourseSchema),
});

그리고 courseApi.ts에서 사용:

-  return apiResponseSchema(
-    z.object({count: z.number(), courses: z.array(dashboardCourseSchema)})
-  ).parse(response.data);
+  return apiResponseSchema(courseListResponseSchema).parse(response.data);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/course/api/courseApi.ts` around lines 6 - 12, Extract the inline
response schema inside getAllCourses into a shared schema exported from
src/entities/course/model/schemas.ts (e.g. export const courseListResponseSchema
= z.object({count: z.number(), courses: z.array(dashboardCourseSchema)})), then
import and use that schema in courseApi.ts by replacing the inline z.object with
courseListResponseSchema when calling apiResponseSchema(...). Keep references to
dashboardCourseSchema and apiResponseSchema unchanged.

src/pages/unit-editor/UnitEditorPage.tsx (1)

39-45: 인덱스 계산 로직 개선 가능

IIFE(즉시 실행 함수)를 사용한 currentIndex 계산이 약간 복잡합니다. useMemo를 사용하면 의존성을 명확히 하고 불필요한 재계산을 방지할 수 있습니다.

♻️ useMemo 활용 제안

const currentIndex = useMemo(() => {
  if (currentMode === 'creating') {
    return (data?.unitCount ?? 0) + 1;
  }
  const index = data?.unitList?.findIndex((u) => u.id === currentUnitId);
  return index !== undefined && index >= 0 ? index + 1 : 1;
}, [currentMode, data?.unitCount, data?.unitList, currentUnitId]);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/unit-editor/UnitEditorPage.tsx` around lines 39 - 45, Replace the
IIFE that computes currentIndex with a useMemo so the value is recomputed only
when relevant dependencies change: move the logic inside a useMemo callback
referencing currentMode, data?.unitCount, data?.unitList, and currentUnitId;
keep the same branching (return (data?.unitCount ?? 0) + 1 when currentMode ===
'creating', otherwise find index via data?.unitList.findIndex(u => u.id ===
currentUnitId) and return index >= 0 ? index + 1 : 1) and export the memoized
result as currentIndex.

src/entities/student/model/schemas.ts (1)

22-23: 날짜 필드 검증 강화 고려

startDate와 endDate가 z.string()으로만 검증됩니다. API 응답이 항상 유효한 날짜 형식을 보장하지 않는다면, 추가 검증을 고려해보세요.

♻️ 날짜 검증 강화 예시

// ISO 날짜 형식 검증
startDate: z.string().datetime(),
// 또는 커스텀 정규식
startDate: z.string().regex(/^\d{4}-\d{2}-\d{2}$/),

Zod 날짜 검증 참고: Zod Strings - datetime

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/student/model/schemas.ts` around lines 22 - 23, Replace the weak
string-only validators for startDate and endDate in the student schema with a
stronger date validation: update the startDate and endDate validators in the
schema (the fields named startDate and endDate) to use z.string().datetime() for
ISO datetimes or z.string().regex(/^\d{4}-\d{2}-\d{2}$/) for YYYY-MM-DD, or
alternatively coerce to a Date with z.coerce.date() if you want Date objects;
ensure both fields are changed consistently and add tests to cover invalid
formats.

src/entities/student/model/types.ts (1)

12-12: 명확한 타입명 규칙 일관성을 위해 Unit을 StudentUnit으로 변경 고려

현재 src/entities/student/model/types.ts의 Unit 타입이 사용되지 않고 있어 실제 충돌은 없으나, 코드의 명확성과 일관성 측면에서 개선할 수 있습니다.

다른 student 타입들(StudentProgress, Student)이 명시적으로 접두사를 가지고 있는데 반해, Unit은 src/entities/unit/model/types.ts의 Unit과 동일한 이름을 사용하고 있습니다. 미래의 혼동을 방지하고 명확성을 높이기 위해 StudentUnit으로 변경하는 것을 권장합니다.

♻️ 타입명 변경 제안

-export type Unit = z.infer<typeof studentUnitSchema>;
+export type StudentUnit = z.infer<typeof studentUnitSchema>;

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/student/model/types.ts` at line 12, Rename the exported type
Unit to StudentUnit to avoid collision with the unit model and to match other
student-prefixed types: update the export in src/entities/student/model/types.ts
from "export type Unit = z.infer<typeof studentUnitSchema>;" to "export type
StudentUnit = z.infer<typeof studentUnitSchema>;", then find and update all
usages/imports of Unit that refer to the student schema (e.g., places importing
Unit from this module) to import and use StudentUnit instead, and adjust any
tests/types that reference studentUnitSchema-derived types accordingly so
symbols remain consistent.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

src/entities/auth/api/authApi.ts (1)

16-16: Zod 파싱 실패 시 에러 처리가 필요합니다.

kakaoLoginResponseSchema.parse()는 유효성 검증 실패 시 ZodError를 throw합니다. 현재 코드에서는 이 예외를 처리하지 않아, API 응답이 예상과 다를 경우 호출부에서 예기치 않은 에러가 발생할 수 있습니다.

두 가지 접근 방법을 고려해 보세요:

1. safeParse 사용: 에러를 throw하지 않고 결과 객체로 반환
2. try-catch로 감싸기: ZodError를 의미 있는 에러로 변환

🛡️ safeParse를 활용한 개선 예시

- const data = kakaoLoginResponseSchema.parse(response.data.response);
+ const result = kakaoLoginResponseSchema.safeParse(response.data.response);
+ if (!result.success) {
+   console.error('API 응답 검증 실패:', result.error.flatten());
+   throw new Error('로그인 응답 형식이 올바르지 않습니다.');
+ }
+ const data = result.data;

📚 참고: Zod 공식 문서 - safeParse

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/auth/api/authApi.ts` at line 16,
kakaoLoginResponseSchema.parse(response.data.response)에서 ZodError가 throw될 수 있으니
예외 처리를 추가하세요: 대신 kakaoLoginResponseSchema.safeParse(response.data.response)를 사용해
결과.ok를 체크하고 실패 시 적절한 에러 객체(예: ApiError 또는 명확한 메시지와 함께 status code)를 반환하거나, 기존 호출
흐름에 맞게 실패를 throw 하도록 구현하거나, 대안으로 parse 호출을 try-catch로 감싸고 catch에서 ZodError를 잡아
의미 있는 오류로 변환해서 던지거나 로깅하도록 변경하세요; 참조 대상 심볼: kakaoLoginResponseSchema.parse,
response.data.response, kakaoLoginResponseSchema.safeParse.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

src/entities/student/model/types.ts (1)

3-8: 절대 경로 import로 통일해 주세요

Line 3-8은 상대 경로(./schemas)라서 프로젝트 규칙과 어긋납니다. alias 경로(@/...)로 맞추면 모듈 이동/리팩터링 시 안정성이 좋아집니다.
참고: https://nextjs.org/docs/app/building-your-application/configuring/absolute-imports-and-module-aliases

변경 제안

 import {
   progressStatusSchema,
   studentProgressSchema,
   studentUnitSchema,
   studentSchema,
-} from './schemas';
+} from '@/entities/student/model/schemas';

As per coding guidelines src/**: "절대 경로 임포트(@/...) 사용".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/student/model/types.ts` around lines 3 - 8, The import in
types.ts currently pulls progressStatusSchema, studentProgressSchema,
studentUnitSchema, and studentSchema via a relative path ('./schemas'); update
that import to use the project alias/absolute path (e.g., '@/...') so it follows
the src/** coding guideline and remains stable during refactors—locate the
import that references './schemas' and replace it with the corresponding alias
import for the same exported symbols.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

src/entities/assignment/api/assignmentApi.ts (1)

4-4: 절대 경로 임포트로 통일해 주세요.

Line 4는 상대 경로(../model/schemas)를 사용하고 있어 이 파일의 나머지 임포트 스타일과도 불일치합니다. alias 경로(@/...)로 맞추는 편이 리팩터링 내성이 좋습니다.

변경 제안

-import {assignmentScheduleSchema} from '../model/schemas';
+import {assignmentScheduleSchema} from '@/entities/assignment/model/schemas';

As per coding guidelines src/**: "절대 경로 임포트(@/...) 사용".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/assignment/api/assignmentApi.ts` at line 4, Replace the relative
import of assignmentScheduleSchema with the project's absolute alias import
form; locate the import statement that references assignmentScheduleSchema and
change it from a "../" relative path to the alias-based path used across the
codebase (use the "@/..." alias to point to the model/schemas module) so imports
are consistent and refactor-safe.

src/entities/unit/model/schemas.ts (1)

23-25: 날짜 문자열 비교 방식 확인 필요

releaseDate <= dueDate 비교는 ISO 8601 형식(YYYY-MM-DD)일 때만 올바르게 동작합니다. 입력 형식이 다르거나 시간이 포함된 경우 예상치 못한 결과가 발생할 수 있습니다.

현재 type='date' 입력을 사용하고 있어 ISO 형식이 보장되지만, 방어적 코딩을 위해 Date 객체로 변환 후 비교하는 것도 고려해볼 수 있습니다:

💡 Date 객체 비교 방식 제안

  .refine((data) => data.releaseDate <= data.dueDate, {
+  // 또는 더 안전한 Date 비교:
+  // .refine((data) => new Date(data.releaseDate) <= new Date(data.dueDate), {
    message: '날짜 범위가 올바르지 않습니다.',
    path: ['dueDate'],
  });

Zod 공식 문서 - Refine

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/entities/unit/model/schemas.ts` around lines 23 - 25, The refine check in
schemas.ts currently compares releaseDate <= dueDate as strings; change the
.refine on the schema that references releaseDate and dueDate to parse both into
Date objects (e.g., via new Date(...) or Date.parse) and compare their numeric
time values (dateA.getTime() <= dateB.getTime()), also ensure you guard against
invalid dates (isNaN) and return false (with the same message/path) when parsing
fails so invalid inputs are rejected.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

src/pages/select-assignment/ui/AssignmentListContainer.tsx (1)

5-12: 제네릭 계약이 흐려져 타입 결합도가 올라갔습니다

AssignmentListContainerProps<T>는 제네릭인데 onSelect/handleSelect는 Assignment로 고정되어 있습니다. 현재 동작은 가능해도, 타입 소스가 2갈래라 이후 변경 시 깨지기 쉽습니다. 단일 타입(AssignmentCourse['assignments'][number])으로 통일하는 편이 유지보수에 유리합니다.
참고: https://www.typescriptlang.org/docs/handbook/2/generics.html

타입 통일 예시 diff

-import type {Assignment} from '@/entities/assignment/model/types';
 import type {AssignmentCourse} from '@/entities/course/model/types';
 import type {MouseEvent, ReactNode} from 'react';

-type T = AssignmentCourse['assignments'][number];
+type AssignmentItem = AssignmentCourse['assignments'][number];

-interface AssignmentListContainerProps<T> {
-  items: T[];
-  renderItem: (item: T) => ReactNode;
+interface AssignmentListContainerProps {
+  items: AssignmentItem[];
+  renderItem: (item: AssignmentItem) => ReactNode;
   title: string;
-  onSelect?: (item: Assignment) => void;
+  onSelect?: (item: AssignmentItem) => void;
 }

 const AssignmentListContainer = ({
   onSelect,
   items,
   renderItem,
   title,
-}: AssignmentListContainerProps<T>) => {
-  const handleSelect = (item: Assignment, event: MouseEvent) => {
+}: AssignmentListContainerProps) => {
+  const handleSelect = (item: AssignmentItem, event: MouseEvent<HTMLButtonElement>) => {
     event.stopPropagation();
     onSelect?.(item);
   };

Also applies to: 19-23

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/pages/select-assignment/ui/AssignmentListContainer.tsx` around lines 5 -
12, AssignmentListContainerProps<T> currently accepts a generic T but the
onSelect/handleSelect callbacks are fixed to Assignment, creating a mixed
contract; change the props and related handlers to use a single concrete type
AssignmentCourse['assignments'][number] (remove/replace the generic T) so items,
renderItem, onSelect, and any handleSelect function all share the same type
(update AssignmentListContainerProps, the items prop, renderItem signature, and
handleSelect/onSelect declarations to reference
AssignmentCourse['assignments'][number] consistently).

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro